Dynamic 2D imposters of 3D graphic objects

ABSTRACT

2D imposters representing 3D graphical objects, such as virtual spectators in a simulated sports arena, are dynamically displayed at predefined locations relative to an arbitrarily movable camera position in a virtual space. A hierarchical data structure is created with branches corresponding to iteratively subdivided groups of imposter data structures and is used to store polygon vertices, texture data, and other 2D imposter data generated during run-time. Center locations of the hierarchically divided groupings are used to determine a common projection location within a current view volume at which each 2D imposter is projected as an oriented image from each corresponding animated 3D graphical object. Sets of contiguous 2D imposter data are determined based on currently visible groupings of predefined locations that do not require rendering as 3D graphical objects due to their distance from the camera position. Each set of contiguous 2D imposters is rendered with a single draw primitive.

FIELD OF THE INVENTION

The present invention generally relates to dynamically creating andupdating two-dimensional (2D) imposters of three-dimensional (3D)graphic objects, and more specifically, pertains to generating 2Dimposters at a common projection point and rendering a large number of2D imposters using minimal drawing primitive functions.

BACKGROUND OF THE INVENTION

Realistically rendering crowds, vegetation, and other animatedbackground objects has always been a difficult problem in video games.For realism, one must render a large number of models with substantialvariety in motion and textures. However, a crowd or other background isusually not the main focus of a scene, so given the limitations onprocessing power, only a limited amount of the available processingpower can be dedicated to rendering the background in a scene.

Rendering an entire crowd in 3D would be prohibitive with currenthardware. Instead, most games use a relatively crude technique to rendera crowd, in which a set of crowd members are pre-rendered and stored ina bank of textures. At run-time, the game simply applies theses textureson rows of rectangles. Just like in cartoons, the impression of motionis given by rapidly switching from one texture to another. Thistechnique is fast, but is quite memory consuming. The game must store atexture for each crowd member, for each frame in every animation. Theother drawback of this technique is that it only looks realistic so longas the view point (or camera) is sufficiently far from the polygonsrepresenting the crowd and remains perpendicular to them. As soon as theview point or camera gets too close, the illusion is broken, because theeye readily perceives the “flat” aspect of the polygons used to renderthe crowd.

A technique for disguising the flat appearance of a background employs apair of orthogonal polygons for each object. In this way, a changingimage is visible as the view point or camera moves around the orthogonalpolygons. However, if the camera moves above or below the orthogonalpolygons, the edges of the polygons are visible, which destroys therealism.

Another current technique uses images taken from multiple 3D directionsof an individual 3D model; each such image is stored as a texture. Thetexture that most closely matches the current camera angle is thenrendered. However, this technique requires a large amount of storage forstoring multiple textures of multiple 3D models. Even more storage isrequired if each model is depicted in a number of animated positions,because each position requires multiple textures for the multipledirections.

A fundamental problem with these prior art techniques is that they treateach object individually. Each polygon and/or texture must be recomputedrelative to a new view point or camera position during each image frame.This computation requires excessive processor cycles although each viewpoint involves only a slightly different angle for each polygon.Although, computing the perfect angle for each polygon is accurate, suchprecision is not required for backgrounds. Instead, it is preferable totreat a large number of similar objects together so as to reduceprocessor cycles and memory requirements. Current techniques are simplynot able to provide realistic backgrounds in a scene without requiringunavailable processing power and/or excessive memory to storepre-rendered elements.

SUMMARY OF THE INVENTION

The present invention is directed to a method and system for dynamicallydisplaying 2D imposters of 3D graphical objects relative to anarbitrarily movable camera position. Each 2D imposter comprises aprojection of one of the 3D graphical objects and is duplicatedthroughout a virtual space, along with 2D imposters of the other 3Dgraphical objects, minimizing processor time and memory, yet providingsufficient variety to provide a realistic animated background. Locationsare predefined within the virtual space at which a 2D imposter or a 3Dgraphical object will be rendered during run-time, depending on eachlocation's proximity to a current camera position. These predefinedlocations are iteratively divided into hierarchical groupings thatinclude substantially equal numbers of adjacent predefined locations.Associated with each predefined location is an imposter data structurethat defines a 2D imposter. Each imposter data structure comprisesvertex data elements that define a polygon onto which texture data ofthe 2D imposter will be rendered. The imposter data structures arearranged in a contiguous quad order and are associated with eachhierarchical group to which the corresponding predefined locationsbelong. Thus, a hierarchical data structure is created as a tree whosebranches correspond to hierarchically subdivided groups of imposter datastructures that are used to store data generated during run-time for 2Dimposters.

During run-time, when a current camera position and view volume isdetermined, the tree is used to create or update 2D imposters from the3D graphical objects. The hierarchical groupings are used to determine acommon projection location within the view volume at which each 2Dimposter is generated from each corresponding 3D graphical object. Morespecifically, the common projection location is determined as a weightedaverage of center coordinates determined for each grouping of predefinedlocations that is within a modulated distance of the current cameraposition relative to a centroid of the view volume. The modulateddistance is determined as a function of a current zoom factor and otherfactors. Preferably, a current animation of each 3D graphical object isalso determined, so that the current pose of each 3D graphical objectcan be projected at the common projection location to generate thecorresponding 2D imposters.

Once the 2D imposters are created or updated, they are rendered atappropriate predefined locations. However, to improve renderingefficiency, 2D imposters are rendered in sets, using a single drawprimitive to render a lot of 2D imposters as one texture for each set.Sets comprise contiguous groupings of predefined locations andcorresponding imposter data. To determine the sets, the hierarchicalgroupings are first evaluated relative to the current view volume todetermine the groupings that have at least one predefined location,which is visible to the camera. These visible groupings are evaluated todetermine which are within a modulated distance of the current cameraposition and should be rendered with 3D graphical objects. Thismodulated distance is also preferable determined as a function of thezoom factor and other factors. The visible groupings that will berendered with 3D graphical objects represent a discontinuity in thevisible groupings. Thus, a set of 2D imposters that will be renderedwith a single draw primitive comprises contiguous visible groupingsbetween non-visible groupings and/or a grouping of 3D graphical objects.Once the sets of 2D imposters are determined, they are preferably sortedin order from the set closest to the current camera position to the setfarthest from the current camera position. Preferably, the closer 3Dgraphical objects are rendered prior to even the closest set of 2Dimposters to prevent rendering pixels of 2D imposters that are blockedby the 3D graphical objects in front of the 2D imposters, therebyincreasing rendering speed. Once the 3D graphical objects are rendered,each set of 2D imposters is rendered with a single draw primitive. Asthe camera position changes in successive execution frames, thetransition between 3D graphical objects and 2D imposters also changesdynamically. Thus, highly realistic 3D graphical objects are alwaysrendered at the predefined locations that are currently closest to auser's current view point, and sets of 2D imposters are always renderedat the predefined locations that are currently beyond the 3D graphicalobjects.

Another aspect of the invention is directed to a memory medium thatstores machine instructions for carrying out the steps described aboveand in accord with the present invention, as discussed in further detailbelow.

BRIEF DESCRIPTION OF THE DRAWING FIGURES

The foregoing aspects and many of the attendant advantages of thisinvention will become more readily appreciated as the same becomesbetter understood by reference to the following detailed description,when taken in conjunction with the accompanying drawings, wherein:

FIG. 1 illustrates an exemplary electronic gaming system that includes agame console and support for up to four user input devices;

FIG. 2 is a functional block diagram showing components of the gamingsystem of FIG. 1 in greater detail;

FIG. 3 is a schematic diagram showing an exemplary network gamingenvironment that interconnects multiple gaming systems like that shownin FIGS. 1 and 2 over a network;

FIG. 4 illustrates a top view of an exemplary 3D virtual spacecomprising a simulated sports arena;

FIG. 5 illustrates how a spectator section is subdivided into a numberof cells;

FIG. 6 is a flow diagram illustrating logic for an offline artistpreprocess;

FIG. 7 is a flow diagram illustrating logic for generating thehierarchical data structure as a quad tree;

FIG. 8 is a flow diagram illustrating logic for rendering 2D impostersand 3D models of spectators during run-time execution of a game or othersimulation;

FIG. 9 is a flow diagram illustrating logic for determining a projectionpoint at which 2D imposters are generated from posed 3D models;

FIG. 10 is a flow diagram illustrating logic for determining aprojection point modulation function (PPMF), used in determining theprojection point;

FIG. 11 provides a graphical example for determining the projectionpoint position;

FIG. 12 is a flow diagram illustrating logic for determining whether toevaluate a next lower level of groupings to determine more centers andcorresponding PPMFs, used in determining the projection point; and

FIG. 13 is a flow diagram illustrating logic for rendering the 3D modelsand 2D imposters of the visible spectator sections.

DESCRIPTION OF THE PREFERRED EMBODIMENT

A preferred embodiment of the present invention is described below inregard to an exemplary use in providing a simulated crowd of spectatorsfor an electronic gaming system that is designed to execute gamingsoftware in coordination with a network gaming service. Those skilled inthe art will recognize that the present invention may also beimplemented for displaying 2D imposters of other graphical objects suchas terrain objects, structures, vegetation objects, almost any type ofobjects that are not the primary focus of a display scene. It is alsoemphasized that the present invention can be practiced on a variety ofcomputing machines such as a personal computer (PC), a set-top box, anarcade game, a hand-held device, and other related systems that displaya virtual environment having a background.

Exemplary Operating Environment

As shown in FIG. 1, an exemplary electronic gaming system 100 that issuitable for practicing the present invention includes a game console102 and support for up to four user input devices, such as controllers104 a and 104 b. Game console 102 is equipped with an internal hard diskdrive (not shown in this Figure) and an optical media drive 106 thatreads various forms of portable optical storage media, as represented byan optical storage disc 108. Examples of suitable portable storage mediainclude digital versatile discs (DVDs) and compact disc-read only memorydiscs (CD-ROMs). In this gaming system, game programs are preferablydistributed for use with the game console on DVD discs, but it is alsocontemplated that other storage media might instead be used on this orother types of systems that employ the present invention.

On a front face of game console 102 are four slots 110 for connection tosupported controllers, although the number and arrangement of the slotsmay be modified as needed to support more or fewer controllers. A powerbutton 112 and an eject button 114 are also positioned on the front faceof game console 102. Power button 112 controls application of electricalpower to the game console, and eject button 114 alternately opens andcloses a tray (not shown) of optical media drive 106 to enable insertionand extraction of storage disk 108, so that the digital data on it canbe read for use by the game console.

Game console 102 connects to a television 121 or other display, monitor,or screen via audio/visual (A/V) interface cables 120. A power cableplug 122 conveys electrical power to the game console when connected toa conventional alternating current line source (not shown). Game console102 includes an Ethernet data connector 124 to transfer and receive dataover a network (such as through a connection to a hub or a switch (notshown), or over the Internet, for example, through a connection to anxDSL interface, a cable modem, or other broadband interface (not shown).Other types of game consoles that implement the present invention may becoupled together or to a remote server, by communicating using aconventional telephone modem.

Each controller 104 a and 104 b is coupled to game console 102 via alead (or alternatively through a wireless interface). In the illustratedimplementation, the controllers are USB compatible and are connected togame console 102 via USB cables 130; however, it is contemplated thatother types of data interfaces may instead be employed. Game console 102may be equipped with any of a wide variety of user devices forinteracting with and controlling the game software. As illustrated inFIG. 1, each controller 104 a and 104 b is equipped with two thumbsticks132 a and 132 b, a D-pad 134, buttons 136, and two triggers 138. Thesecontrollers are merely representative, and other gaming input andcontrol devices may be substituted for or added to those shown in FIG. 1for use with game console 102.

A removable function unit 140 can optionally be inserted into eachcontroller 104 a and 104 b to provide additional features and functions.For example, a portable memory unit (MU) enables users to store gameparameters and port them for play on other game consoles, by insertingthe portable MU into a controller connected to the other game console.Another removable functional unit comprises a voice communication unitthat enables a user to verbally communicate with other users locallyand/or over a network. Connected to the voice communication unit is aheadset 142, which includes a boom microphone 144. The circuitry of thevoice communication unit may alternatively be integrated into thecontroller, and a headset with boom microphone may be removably orpermanently connected to the controller. Preferably, each controller isconfigured to accommodate two removable function units, although more orfewer than two removable function units or modules may instead beemployed.

Gaming system 100 is capable of playing, for example, games, music, andvideos. It is contemplated that other functions can be implemented usingdigital data stored on the hard disk drive or read from optical storagedisc 108 in drive 106, or using digital data obtained from an onlinesource, or from a MU. For example, gaming system 100 is capable ofplaying:

-   -   Game titles stored on CD and DVD discs read by the optical media        drive, stored on the hard disk drive, or downloaded from an        online source;    -   Digital music stored on a CD read by optical media drive 106, in        a file on the hard disk drive (e.g., WINDOWS MEDIA AUDIO™ (WMA)        format), or derived from online streaming sources on the        Internet or other network; and    -   Digital A/V data stored on a DVD disc read by optical media        drive 106, or in files stored on the hard disk drive (e.g., in        an Active Streaming Format), or accessed from online streaming        sources over the Internet or other network.

FIG. 2 shows functional components of gaming system 100 in greaterdetail. Game console 102 includes a CPU 200, a memory controller 202that facilitates CPU access to a read-only memory (ROM) 204, a randomaccess memory (RAM) 206, a hard disk drive 208, and portable opticalmedia drive 106. CPU 200 is equipped with a level 1 cache 210 and alevel 2 cache 212 to temporarily store data so as to reduce the numberof memory access cycles required, thereby improving processing speed andthroughput of the gaming system. CPU 200, memory controller 202, andvarious memory devices are interconnected via one or more buses,including serial and parallel buses, a memory bus, a peripheral bus, anda processor or local bus using any of a variety of bus architectures. Byway of example, such architectures can include an Industry StandardArchitecture (ISA) bus, a micro channel architecture (MCA) bus, anenhanced ISA (EISA) bus, a Video Electronics Standards Association(VESA) local bus, and a peripheral component interconnect (PCI) bus.

As an example of one suitable implementation, CPU 200, memory controller202, ROM 204, and RAM 206 are integrated onto a common module 214. Inthis implementation, ROM 204 is configured as a flash ROM that isconnected to memory controller 202 via a PCI bus and a ROM bus (neitherof which are shown). RAM 206 is configured as multiple double data ratesynchronous dynamic RAM modules (DDR SDRAM modules) that areindependently controlled by memory controller 202 via separate buses(not shown). Hard disk drive 208 and optical media drive 106 areconnected to the memory controller via the PCI bus and an advancedtechnology attachment (ATA) bus 216.

A 3D graphics processing unit (GPU) 220 and a video encoder 222 form avideo processing pipeline for high-speed and high-resolution graphicsprocessing. Data are conveyed from GPU 220 to video encoder 222 via adigital video bus (not shown). An audio processing unit 224 and an audioencoder/decoder (CODEC) 226 form a corresponding audio processingpipeline for high fidelity and stereo audio data processing. Audio dataare conveyed between audio processing unit 224 and audio CODEC 226 via acommunication link (not shown). The video and audio processing pipelinesoutput data to an A/V port 228 for transmission to the television orother display monitor. In the illustrated implementation, video andaudio processing components 220-228 are mounted on module 214.

Also implemented on module 214 are a USB host controller 230 and anetwork interface 232. USB host controller 230 is coupled to CPU 200 andmemory controller 202 via a bus (e.g., the PCI bus), and serves as ahost for peripheral game controllers 104 a-104 d. Network interface 232provides access to a network (e.g., the Internet, home network, etc.)and may include any of a wide variety of various wire or wirelessinterface components, including an Ethernet card, a telephone modeminterface, a Bluetooth module, a cable modem interface, an xDSLinterface, and the like.

Game console 102 has two dual controller support subassemblies 240 a and240 b, and each subassembly supports two of game controllers 104 a-104d. A front panel input/output (I/O) subassembly 242 supports thefunctionality of power button 112 and eject button 114, as well as anylight emitting diodes (LEDs) or other indicators exposed on the outersurface of the game console. Subassemblies 240 a, 240 b, and 242 arecoupled to module 214 via one or more cable assemblies 244.

Eight function units 140 a-140 h are illustrated as being connectable tofour controllers 104 a-104 d, i.e., two function units for eachcontroller. Each function unit offers additional functionality orstorage for games, game parameters, and other data. When an MU isinserted into a controller, the MU can be accessed by memory controller202.

A system power supply module 250 provides power to the components ofgaming system 100. A fan 252 cools the components and circuitry withingame console 102.

To implement the present invention, a game software application 260comprising machine instructions stored on a DVD or other storage media(or downloaded over the network) is loaded into RAM 206 and/or caches210 and/or 212 for execution by CPU 200. Portions of softwareapplication 260 may be loaded into RAM only when needed, or all of thesoftware application (depending on its size) may be loaded into RAM 206.Software application 260 and the relevant functions that it performs toimplement the present invention are described below in greater detail.

Gaming system 100 may be operated as a stand-alone system by simplyconnecting the system to a television or other display monitor. In thisstand-alone mode, gaming system 100 enables one or more users to playgames, watch movies, or listen to music. However, with connectivity tothe Internet or other network, which is made available through networkinterface 232, gaming system 100 may be further operated as a componentof a larger network gaming community, to enable online multiplayerinteraction in games that are played over the Internet or other networkwith players using other gaming systems. Gaming system 100 can also becoupled in peer-to-peer communication with another gaming system usingthe network interface and an appropriate cable (not shown).

Network System FIG. 3 shows an exemplary network gaming environment 300that interconnects multiple gaming systems 100 a, . . . 100 n via anetwork 302. Preferably, each gaming system includes at least onecorresponding headset 142 a, ... 142 n and corresponding microphone 144a, . . . 144 n for voice communication between players. Network 302represents any of a wide variety of data communication networks and mayinclude public portions (e.g., the Internet), as well as privateportions (e.g., a residential or commercial local area network (LAN)).Network 302 may be implemented using any one or more of a wide varietyof conventional communication configurations, including both wired andwireless types. Any of a wide variety of communications protocols can beused to communicate data via network 302, including both public andproprietary protocols. Examples of such protocols include TCP/IP,IPX/SPX, NetBEUI, etc.

In addition to gaming systems 100 a, . . . 100 n, one or more onlineservices 304 a, . . . 304 s are accessible via network 302 to providevarious services for the participants, such as serving and/or hostingonline games, serving downloadable music or video files, hosting gamingcompetitions, serving streaming A/V files, enabling exchange of email orother media communications, and the like. Network gaming environment 300may further employ a key distribution center 306 that plays a role inauthenticating individual players and/or gaming systems 100 a, . . . 100n for interconnection to one another, as well as to online services 304a, . . . 304 s. Distribution center 306 distributes keys and servicetickets to valid subscribing participants that may then be used to formgame playing groups of multiple players, or to purchase services fromonline services 304 a, . . . 304 s.

Network gaming environment 300 introduces another memory sourceavailable to individual gaming systems 100 a, . . . 100 n, i.e., onlinestorage. In addition to accessing data on optical storage disk 108, harddisk drive 208, and function unit 140, gaming systems 100 a, . . . 100 ncan also access data files available at remote storage locations vianetwork 302, as exemplified by remote storage 308 at online service 304s.

Network gaming environment 300 further includes a developer service 309with which developers can produce media effects, updated media data,game code, and other services. Such services can be distributed betweenthe online services and the producers of games for the gaming systems,and between other devices within, and outside of network gamingenvironment 300. It should be noted that in a preferred form, thenetwork gaming environment is a closed network, providing only access toother gaming systems and the gaming environment, using communicationthrough virtual private network tunnels to provide enhanced security andpreclude access by other computing devices.

Exemplary Process

A preferred embodiment of the present invention is directed to a game orother simulation that includes a simulated crowd of spectators. FIG. 4illustrates a top view of an exemplary 3D virtual space comprising asimulated sports arena 350. Sports arena 350 includes a play area 352where simulated activities occur and is generally the focus of the 3Dvirtual space. Surrounding play area 352 is a spectator area 354, whichis preferably divided into a number of sections. Although FIG. 4 shows a2D view, those skilled in the art will recognize that each arearepresents a 3D volume in the virtual environment depicted. For example,spectator area 354, preferably represents a volume of tiered spectatorseating. Each section comprises a number of virtual spectators that areall oriented to appear to be viewing play area 352. Preferably, agraphical artist predefines locations within each section at whichvirtual spectators are to be displayed. A large number of virtualspectators will typically be shown within each section to provide morerealism for the computer game or other simulation.

However, realism must be balanced against memory and computing resourcelimitations. Because the virtual spectators are generally consideredonly background, very limited resources are allocated for displayingspectators relative to the resources allocated for computing anddisplaying primary activities within play area 352. For example, to runon a game console with limited capabilities, a game may allocate only500 kB of memory to store all of the data needed for rendering all ofthe spectators in spectator area 354. In contrast, the game may allocate16 MB of memory for computing and displaying activities that are theprimary focus in play area 352. Nevertheless, a high level of realismcan be obtained by using a combination of 3D models of virtualspectators and 2D imposters of the 3D models in accord with the presentinvention. Also, because the spectators are generally stationary withinspectator area 354, groups of spectators can be processed together.Although the spectators are generally stationary, the spectators arepreferably animated and depicted as moving their bodies in response tothe activities occurring in play area 352. For example, some spectatorsare preferably animated to stand and cheer when a point is scored inplay area 352. Also, a camera view preferably changes dynamically as afunction of activities in play area 352 and also as a function of userinput. Thus, dynamic updating of the spectators is desired to improverealism and enhance a user's experience with the game or othersimulation.

To minimize the resources needed and ensure a minimum display framerate, one section of spectators is preferably updated per display frame.For example, a section 0 356 can be updated within a frame as describedin further detail below. For discussion purposes, a camera position 358is disposed in a corner of section 0 356 and a view volume 360 extendsfrom camera position 358 toward a central area of section 0 356. Viewvolume 360 preferably comprises a frustum encompassing a desired view tobe displayed.

To improve the efficiency in updating a spectator section, the spectatorsection is hierarchically subdivided into a number of groupings,including groups, subgroups, and cells. FIG. 5 illustrates how section 0356 is subdivided into a number of cells. Each cell comprises up to amaximum predefined number of spectator locations. For example, cell 0362 can comprise approximately 20 spectator locations at which either 3Dspectators or 2D imposters will be rendered. The cells are arranged in ahierarchical quad order such that each cell and grouping of cells arecontiguous. By arranging the cells and groupings of cells in contiguousquad order, sets of cells can be rendered with a single draw primitive.For example, a set 364 (indicated by the diagonal lines in FIG. 5) canbe rendered with 2D imposter spectators using a single draw primitive,because cells numbered 3 through 9 are contiguous under the hierarchicalquad ordering.

However, the set ends when a next contiguous cell cannot be included. Inthe example illustrated in FIG. 5, a cell 10 366 cannot be included inset 364, because the spectator locations of cell 10 366 are disposed soclose to camera position 358 that 3D spectators will be rendered in cell10 366 rather than the 2D imposter spectators that will be rendered inthe contiguous cells of set 364. Another set 368 of the remainingcontiguous cells within (or intersecting) view volume 360 will berendered with a single draw primitive to display 2D imposter spectators.Another interruption in contiguous cells' can result when a next celllies completely outside of the view volume. In that case, none of thespectator positions of the outside cell are visible, so the outside cellis not included in the contiguous set, and no imposters need be renderedfor the outside cell. Further details regarding the hierarchicalstructure, the contiguous sets, and the cells that will include 2Dimposter spectators are discussed below.

FIG. 6 is a flow diagram illustrating the logic for an offline artistpreprocess that is initially implemented. At a step 370, a computergraphics artist creates 3D models of spectators and animation sequencesfor each of the 3D models. For example, the artist may create a numberof different types of 3D models such as a tall male spectator, a femalespectator, a child spectator, a concession vendor, and other types ofcrowd members. One of the 3D models will typically comprise an emptyseat, but such an object still represents a spectator as that term isused herein. Each spectator can be assigned an animation type reflectingthe type of animation that the spectator will perform. For example, aspectator may be specified as a home team supporter who stands andraises his arms over his head when each time that a point is scored by ahome team player. Alternatively, a spectator may be specified as avisiting team supporter who makes gestures and appears to shout angrilywhen a point is scored by a home team player, but makes cheeringgestures when the visiting team scores. The 3D models and animationsequences are preferably limited to a predefined number that issufficiently large so that the animations do not appear undulyrepetitious. Duplicates of the spectators are preferably distributedthroughout the spectator area so as to make the overall crowd appeardiverse, even though the number of different 3D models and 2D impostersthat need to be calculated and rendered within each display executionframe are limited. Thus, at a step 372, the computer graphics artistspecifies locations throughout the sections of the spectator area foreach of the different spectators. The artist also specifies a texture tobe applied to the different types of spectators. For example, the artistmay specify that a home jersey texture be applied to some of thespectators while a business suit or general casual clothes be applied asthe texture used for other spectators. The artist also preferablyspecifies a color hue to be applied to the spectators at each specifiedlocation. For example, some spectators may be located near an overheadlight, a glowing sign, or other light source that would cast a coloredglow onto the spectators in that area.

Once the artist has specified how the crowd of spectators is to look,move, and be located, this information is stored in a crowdspecification file, at a step 374. In addition to data specifying the 3Dmodels, animation sequences, textures, and locations, the boundaries ofeach spectator section in the virtual arena are also stored in the crowdspecification file.

Based on the data specified by the artist and the sections comprisingthe spectator area, a hierarchical data structure is created offline toimprove processing of the specification information during run-time.FIG. 7 is a flow diagram illustrating the logic for generating thehierarchical data structure as a quad tree. At a step 380, apreprocessing module accesses the crowd specification file. At a step382, the preprocessing module accesses specification data that areassociated with a single section of spectators. The preprocessing modulealso determines the number of spectators associated with that selectedsection. At a step 384, the preprocessing module determines a boundingsphere based on a radius needed to encompass the 3D model with thelargest dimensions. The preprocessing module then assigns a copy of thisbounding sphere to each spectator location in the selected section anddetermines an oriented bounding box that defines the minimum arearectangle that can enclose all of the bounding spheres for the selectedsection. The oriented bounding box will later be checked forintersection with the view volume during run-time to determine whetherany spectators of a specific section are visible in the current view ofthe crowd. The oriented bounding box can be oriented differently thanthe section it represents, but defines the minimum volume required toencompass all the spectators of a section.

At a step 386, the preprocessing module divides the number of spectatorlocations of the selected section into two groups of substantially equalnumbers. The preprocessing module associates each spectator locationwith its corresponding group and stores the associations as part of thetree. Similarly, at a step 388, the preprocessing module iterativelysubdivides each group of spectator locations into four subgroups withapproximately equal numbers of spectator locations, for a total of eightsubgroups. Each spectator location is associated with its correspondingsubgroup, and the association is stored as part of the tree. Again, thepreprocessing module iteratively subdivides each subgroup into fourfurther subgroups, each with substantially equal numbers of spectatorlocations. Each spectator location is thus associated with a number ofdifferent levels of groupings that encompass progressively smallernumbers of spectator locations. At each level of subdivision, thepreprocessing module also determines and stores an oriented bounding boxfor each successively smaller subgroup, based on the bounding spheresdiscussed above. The subdividing process continues until a subdividedgroup of spectator locations is less than or equal to a predefinedmaximum number of spectator locations that define a smallest grouping ofthe spectator locations. This smallest grouping is referred to herein asa cell. A cell corresponds to a final leaf of the hierarchical tree.

At a step 390, the preprocessing module initializes an imposter datastructure for each spectator location of the selected section. Theimposter data structures will be used to store data that define 2Dimposters. For example, an imposter data structure will comprise fourvertex data elements corresponding to four vertices of a polygon thatwill be rendered to display a 2D imposter. Similarly, each imposter datastructure includes elements for storing other data associated with animposter, such as a unique vertex ID for each of the four vertices, atexture ID for the texture assigned to a particular spectator location,a color assigned to the particular spectator location, a center positionassociated with the particular spectator location, and other elementsthat hold data from the crowd specification file and data generatedduring run-time. For example, the exact coordinates of the polygonvertices will not be known until run-time, but the vertex data elementsare predefined and initialized to the center position, so that only anoffset need be calculated for each vertex during run-time. At a step392, the preprocessing module sorts the imposter data structuresaccording to the contiguous quad order defined by the hierarchical tree.In effect, the preprocessing module associates each imposter datastructure with the group, subgroup(s), and cell that encompass thespectator location associated with the imposter data structure. Thissorting is sometimes referred to as “swizzling.” The “swizzled order”corresponds to the quad order illustrated in FIG. 5.

At a step 394 of FIG. 7, the preprocessing module compacts the imposterdata structures and the current data to save storage space. For example,large floating point values can be scaled and offset to a restrictedrange to reduce the amount of memory needed to specify a data value. Ata step 396, the preprocessing module stores the hierarchical tree ofcorresponding imposter data structures and data in a binary file. Thepreprocessing module then determines, at a decision step 398, whetheranother spectator section remains to be divided. If another spectatorsection needs to be processed, control returns to step 382 to access thedata associated with the next spectator section. Once all spectatorsections have been processed to create a hierarchical tree andcorresponding imposter data structures for each section, thepreprocessing stage is complete. Those skilled in the art will recognizethat a single hierarchical tree could be created for the entirecollection of spectator locations. This one hierarchical tree coulddivide all spectator locations into iteratively subdivided groups ratherthan relying on spectator sections predefined by the artist.

FIG. 8 is a flow diagram illustrating the logic for rendering 2Dimposters and 3D models of spectators during run-time execution of agame or other simulation. At a step 400, a run-time process loads datathat were determined in the preprocessing stage described above. Morespecifically, the run-time process loads the crowd specification fileand the binary file of hierarchical trees corresponding to the spectatorsections. At a step 402, the run-time process detects a frame event,which indicates that an updated display frame needs to be generated.Preferably, the frame events occur at a rate of at least thirty framesper second to ensure that the animation appears relatively smooth. At astep 404, the run-time process obtains a current camera position andcamera view direction for use in calculating a view volume such as aview frustum. Because display screens are generally rectangular, theview frustum is determined as a truncated pyramid. The run-time processthen steps through the hierarchical trees to obtain oriented boundingbox information about each group, subgroup, and cell. The run-timeprocess checks for intersections between the view frustum and theoriented bounding boxes to determine and flag, at a step 406, thosespectator sections, groups, subgroups, and cells that are currentlyvisible.

At a step 408, the run-time process. determines a modulated distancebetween the current camera position and the closest edge of eachoriented bounding box for each visible spectator section. The modulateddistance is preferably determined as a function of a current camera zoomfactor, a predefined view range threshold, the area of a spectatorsection encompassed by the view frustum, and/or other factors thataffect the current view of each spectator section. Based on themodulated distance determined for each spectator section, the run-timeprocess selects one of the currently visible sections to be updatedduring the current frame. The selection is preferably a function of thearea of a spectator section's bounding box encompassed within the viewfrustum, a number of frames that have been displayed since a particularspectator section has been updated, and/or other criteria forprioritizing the spectator sections.

Once a spectator section is selected, the run-time process determines aprojection point, at a step 410, at which 2D imposters will be generatedfor all of the 3D models. Details regarding determination of theprojection point are discussed below with regard to FIG. 9. At a step412 of FIG. 8, the run-time process obtains a current animation pose ofeach 3D model. An animation pose of a 3D model corresponds to a step inan animation sequence that is associated with the 3D model. A currentanimation step depend on the current game state, e.g., responding to agame point that was just scored. For each 3D model in its currentanimation pose, the run-time process places the posed 3D model at theprojection point, at a step 414, such that the posed 3D model isoriented generally facing toward the play area. While a posed 3D modelis at the projection point, the run-time process renders 2D image datato a texture storage space, thereby generating a 2D imposter of eachposed 3D model. The 2D imposter is generated relative to the currentcamera position, so the 2D imposter looks 3D, even though the 2Dimposter is flat.

This projection process can be accomplished in various different ways,depending on whether the camera position is close to the spectator areaor far from the spectator area, such as in the middle of the play area.If the camera position is close to the spectator area, each posed 3Dmodel is projected onto a rectangle that is defined by the minimumdimensions needed to bound a particular posed 3D model. Thus, each 2Dimposter will comprise a texture that is fit within a unique minimumrectangle needed to enclose the projection of an individual posed 3Dmodel. Using individually sized rectangles minimizes the number ofunused pixels in each 2D imposter texture. Minimizing unused pixelsmaximizes visual quality of each 2D imposter and reduces the amount ofprocessor time required to render the 2D imposter. For this projectionmethod, the rectangle is also aligned orthogonal to the camera viewdirection and corresponds to a near plane disposed at the point of theposed 3D model that is closest to the camera position. Although theabove-described projection method provides visual accuracy benefits, themethod requires processor time to determine a unique rectangle for eachimposter during run-time. When the camera position is far from thespectator area, an alternative projection method can be used that doesnot require as much processing during run-time. Instead of computing aunique rectangle for each 2D imposter, the run-time process can computea single rectangle based on the largest bounding sphere determined forthe 3D models during the preprocessing stage. Using the largest boundingsphere will result in a larger dimensioned rectangle and more unusedpixels, but eliminates the need to calculate a unique rectangle based oneach uniquely posed 3D model within the time period of a single frame.Further detail regarding these two methods is provided in Appendix A.Those skilled in the art will recognize that other projection techniquescan be used in the alternative.

Once a 2D imposter is generated from each posed 3D model, the run-timeprocess renders 3D models at spectator locations that are close to thecamera position (where detail is more important for realism) and renders2D imposters at spectator locations that are farther from the currentcamera position, at a step 416. The rendering process is discussed belowwith regard to FIG. 13. At a decision step 418, the run-time processdetermines whether the game is over or if other changes in displayprocessing have occurred that would prevent updating the display of thespectators. If such an interruption has occurred, the run-time processreturns control to its parent process. Otherwise, control returns tostep 402 to await detection of another frame event and the start ofanother cycle of updating the display of spectators.

Further detail of the logic employed regarding step 410 (in FIG. 8) isprovided in FIG. 9. This logic determines the projection point at which2D imposters are generated from posed 3D models. At a step 420, aprojection point process determines a volumetric centroid of the viewfrustum. At a step 422, the projection point process begins traversingthe hierarchical tree of the selected spectator section to access datarelated to the first level of the hierarchical tree. In particular, theprojection point process accesses the spectator locations associatedwith a first level group of spectators. At a step 424, the projectionpoint process uses the spectator locations of the current level group todetermine a center of the group. This group center is preferably basedon the spectator locations associated with the group and is not based ongeometric dimensions of a subsection of the currently selected spectatorsection. Also, this group center preferably comprises a volumetriccentroid, but is referred to herein as a group center to simplify thediscussion. Based on this group center location, the projection pointprocess determines a PPMF, at a step 426. Further detail regarding thePPMF is discussed below with regard to FIG. 10.

At a decision step 428 in FIG. 9, the projection point processdetermines whether a center and PPMF should be calculated for the nextlower level of spectator subgroup(s). Further detail regarding thisdetermination is discussed below with regard to FIG. 12. If the centerand PPMF of the next lower subgroup(s) should be determined, theprojection point process sets a current level variable to the next childof the hierarchical tree, at a step 430. This process step iteratesuntil no lower level centers and PPMFs need to be determined. Once thelowest level of the current branch of the hierarchical tree has beenevaluated, and the centers and PPMFs along that traversal path have beendetermined, at a decision step 432, the projection point processdetermines whether a sibling level group is available to evaluate. Ifso, the projection point process sets the current level to the nextsibling group, at a step 434. Control then returns to step 422 todetermine centers and PPMFs for the subgroups and cells of that nextsibling group. Once all of the centers and PPMFs of the appropriategroups, subgroups, and cells have been determined, the projection pointprocess computes the projection point position for the selectedspectator section, at a step 436. The projection point position iscomputed as a weighted average of the centers determined for the groups,subgroups, and cells, wherein the weighted average is a function of thecorresponding PPMFs. Specifically, the projection point position iscomputed as a sum of each center position multiplied by itscorresponding PPMF, divided by a sum of the PPMFs.

FIG. 10 is a flow diagram illustrating the logic for determining a PPMF.At a step 440, the projection point process determines a distancebetween the center (i.e., centroid) of a current group, subgroup, orcell and the centroid of the view frustum. This distance is referred toherein as the frustum distance. At a decision step 442, the projectionpoint process determines whether the center of the current group,subgroup, or cell is within the view frustum. If the view frustumencompasses the center of the current grouping of spectator locations,then the projection point process sets a constant to an inside value, ata step 444. The inside value represents the fact that the center of thecurrent grouping is inside the view frustum. Conversely, if the centerof the current grouping of spectator locations is not within the viewfrustum, the projection point process sets the constant to an outsidevalue, at a step 446. Preferably, the outside value is less than theinside value. The inside and outside values for the constant arepredetermined to control how quickly the PPMF goes to zero, therebycontrolling how much a particular grouping of spectator locationsinfluences the final determination of the projection point. At a step448, the projection point process calculates the PPMF as the quotient of1 divided by the sum of one and product of the constant times thefrustum distance. Once calculated, the projection point process storesthe PPMF for the current grouping, at a step 449.

FIG. 11 provides a graphical example for determining the projectionpoint position. FIG. 11 is a top view of spectator section 0 356, andshows various levels of groupings of spectator locations within thatspectator section. For example, a first level group 450 b encompassesspectator locations in a right half of spectator section 0 356. Asindicated above, the projection point process determines a group center452 b of group 450 b based on the spectator locations within group 450b. The projection point process determines a distance between groupcenter 452 b and a view volume centroid 361, which is preferably thecentroid of the view frustum illustrated by view volume 360. Theprojection point process also determines whether group center 452 b lieswithin the view frustum, and determines a projection point modulationfunction to be associated with group center 452 b. The relative value ofthe PPMF determined for group center 452 b is illustrated by the size ofthe cross mark of group center 452 b. A similar process is performed todetermine a PPMF for a left group center 452 a of a left-half group 450a. Because left group center 452 a is closer to view volume centroid 361and is within view volume 360, the PPMF for left group center 452 a islarger, as illustrated by the larger cross mark of left group center 452a.

Once the group level PPMFs are computed, the projection point processdetermines whether a group should be subdivided into subgroups todetermine PPMFs for centers of the subgroups. In the example of FIG. 11,right group center 452 b is relatively far from view volume centroid 361and camera position 358. Thus, right group 450 b should have less effecton determining a final projection point position 460 than centersassociated with subgroups and cells of left group 450 a. Accordingly,lower level subdivisions of right group 450 b are not evaluated throughthe hierarchical tree branches associated with right group 450 b.

However, the subdivision levels of left group 450 a are evaluated. Inparticular, four subgroups of left group 450 a are evaluated todetermine corresponding centers and PPMFs. For instance, the spectatorlocations of a subgroup 453 b are evaluated to determine a subgroupcenter 454 b. A corresponding PPMF is determined for subgroup center 454b based on the distance between subgroup center 454 b and view volumecentroid 361. The PPMF value determined for subgroup center 454 b canalso depend on its level in the hierarchical tree structure. Forexample, the constant used for calculating the PPMF can be selected ormodified based on each level of subgrouping in the hierarchical treestructure. However, the distance between a subgrouping center and theview volume centroid and/or the camera position preferably has thegreatest influence on the PPMF determined for a particular groupingcenter. Other subgroup centers that affect projection point position 460include subgroup center 454 d and subgroup center 454 c. Note thatsubgroup center 454 c is closer to camera position 358, and therefore,has a greater influence on projection point position 460 than the othercenters. Recall that the centroid of the view volume can be determinedas a modulated centroid based on zoom, field of view, and othercharacteristics. Thus, view volume centroid 361 can be a modulated viewvolume centroid, so that calculation of PPMFs would depend primarily onthe distance between each grouping center and the modulated view volumecentroid and corresponding constant. Regardless of which way the PPMF iscalculated, a close grouping center, such as subgroup center 454 c willhave a larger PPMF, resulting in a larger influence on the finalprojection point position.

Similarly, close cell centers will have a large influence on determiningprojection point position 460. For example, cell centers 456 b and 456 dwill have a large influence on determining projection point position460, since these cell centers are close to camera position 358, areclose to view volume centroid 361, and are within view volume 360.Conversely, cell center 456 a will have less influence, because it isoutside of view volume 360 and farther from view volume centroid 361,even though cell center 456 a is relatively close to camera position358. Accordingly, the PPMF of cell center 456 a is illustrated by asmaller cross mark. Similarly, cell centers 458 b, 458 c, and 458 d willhave correspondingly less influence on determining projection pointposition 460.

FIG. 12 is a flow diagram illustrating logic for determining whether toevaluate a next lower level of groupings to determine more centers andcorresponding PPMFs. At a step 462, the projection point processdetermines a distance between the current camera position and the center(i.e., centroid) of a current group, subgroup, or cell. This distance isreferred to herein as the camera distance. At a decision step 464, theprojection point process determines whether the current grouping isvisible. Preferably, visibility is determined by whether the orientedbounding box of the current grouping intersects the view volume (i.e.,the view frustum). As indicated above, the view volume is preferablysimplified to a frustum of a pyramid to simplify the calculations. Ifthe current grouping is visible, the projection point process determinesa field of view modulation factor (FOVMF) for the current grouping, at astep 466. The FOVMF is preferably determined as a function of the zoom,field of view, and other relevant view factors. If the current groupingis not visible, the projection point process sets the FOVMF equal to 1,at a step 468, so that the camera distance is not modified.

After the FOVMF is determined, the projection point process multipliesthe camera distance by the FOVMF, at a step 470 to create a modulatedcamera distance (MCD). At a step 472, the projection point process thendetermines a quotient from dividing the MCD by a length of the longestaxis of the current grouping. In the examples illustrated in FIG. 11 anddiscussed above, the groupings generally appear square. However, thoseskilled in the art will recognize that the groupings need not be squarebecause the groupings are dependent on the. spectator locations and noton geometric subdivisions of a section. Thus, the axes of a grouping maynot be equal. At a step 474, the projection point process accesses apredefined threshold value associated with a current level of thehierarchical tree. Based on the predefined threshold value and thecalculated quotient, the projection point process determines, at adecision step 476, whether the quotient is less than the predefinedthreshold value. If the quotient is less than the predefined thresholdvalue, the projection point process sets a decision flag, at a step 478,to indicate that the projection point process should evaluate the nextlower level of groupings for centers and corresponding PPMFs. However,if the quotient is greater than (or equal to) the predefined thresholdvalue, the projection point process does not set the flag to evaluate anext level, as illustrated by a step 480. Control then returns todecision step 428 of FIG. 9 to check the decision flag and continueprocessing the logic of FIG. 9 to ultimately compute the projectionpoint position.

Once the projection point position is determined, and the 2D impostersare generated at the projection point position, the run-time process canbegin rendering the 3D models and the 2D imposters. FIG. 13 is a flowdiagram illustrating the logic for rendering the 3D models and 2Dimposters of the visible spectator sections. At a decision step 500, therun-time process determines whether a particular spectator section is atleast partially visible visible. Preferably, this determination is basedon whether a spectator section's bounding box intersects the viewfrustum. If a particular spectator section is visible, the run-timeprocess determines, at a step 502, which corresponding groups,subgroups, and/or cells of the spectator section are located within apredefined modulated radius from the current camera position. Themodulated radius is similar to previously discussed modulated distancesin that the modulated radius is based on the current zoom, field ofview, and other view factors. Those groupings that are within thepredefined modulated radius are rendered with 3D models to providegreater realism at close range. These close groupings are sometimesreferred to herein as 3D groupings.

At a step 504, the run-time process determines the 2D groupings arecontiguous based on the current camera position. For example, asdiscussed above with regard to FIG. 5, sets 364 and 368 comprisecontiguous cells separated by cell 10 366, which will be rendered with3D models. Recall that the contiguous sets of 2D imposters will berendered with one draw primitive per set.

Having determined where 3D models and 2D imposters will be rendered, therun-time process sorts the visible 3D groupings, in a step 506, in orderfrom those groupings that are closest to the camera position to thosegroupings that are furthest from the camera position. In the example ofFIG. 5, only cell 10 366 is within the predefined modulated radius fromthe camera position, so the sorting does not have much effect. At a step508, the run-time process then renders the 3D models of the visible 3Dgroupings.

In a similar fashion, the run-time process sorts the sets of visible 2Dgroupings, at a step 510, starting from the set that is closest to thecamera position to the set that is furthest from the camera position. Inthe example of FIG. 5, set 364 would be considered to come before set368, because set 364 includes two cells that are very close to thecamera position, whereas set 368 has only one cell that is similarlyclose to the camera position.

At a step 512, the run-time process calls a draw primitive function foreach set of 2D groupings. The draw primitive function preferably invokesa vertex shader to calculate vertex position values associated with eachspectator location, thereby defining polygons that are orientedorthogonal to the view direction from the current camera position to theprojection point position. Exemplary vertex shader code is provided inAppendix B. In general, the vertex shader calculates a unique offsetfrom the spectator location to each vertex of the polygon on which a 2Dimposter texture will be rendered. A sample of the vertex calculation isalso provided in Appendix B. Those skilled in the art will recognizethat other methods can be used to calculate the vertices. Having definedthe position and orientation of the polygons for the 2D imposters, thedraw primitive function also invokes a pixel shader to render thespecified 2D imposter texture of the corresponding posed 3D model ateach spectator location in each set of groupings. Another call to thedraw primitive function renders all 2D imposters for each successiveset, until all of the sets are rendered.

At a decision step 514, the run-time process determines whether anotherspectator section is available for processing. If so, control returns todecision step 500 to determine whether the next spectator section isvisible and needs to be rendered. If a spectator section is not visible,control is passed back to decision step 514, and the logic continues toloop until all visible spectator sections are rendered for the currentdisplay frame. The run-time process then awaits the next frame event toupdate and again render the display of spectators.

Although the present invention has been described in connection with thepreferred form of practicing it and modifications thereto, those ofordinary skill in the art will understand that many other modificationscan be made to the present invention within the scope of the claims thatfollow. Accordingly, it is not intended that the scope of the inventionin any way be limited by the above description, but instead bedetermined entirely by reference to the claims that follow.

1. A method for dynamically displaying two-dimensional (2D) impostersrepresenting three-dimensional (3D) graphical objects, relative to anarbitrarily movable camera position, wherein each 2D imposter comprisesa projection of one of the 3D graphical objects, comprising the stepsof: (a) predefining locations within a virtual space, wherein eachlocation defines a position at which one of: (i) a 3D graphical objectwill be displayed; and (ii) a 2D imposter will be displayed; (b)predefining a hierarchical data structure comprising hierarchical groupsof imposter data structures to be used in defining the 2D imposters,wherein each imposter data structure is associated with one of thepredefined locations within the virtual space, and wherein thehierarchical groups are arranged in a contiguous quad order; (c)determining a current camera view volume within the virtual space; (d)determining a common projection location within the current camera viewvolume as a function of a central location of the predefined locationsassociated with each hierarchical group of imposter data structures; (e)generating each of the 2D imposters as a projection of each 3D graphicalobject positioned at the common projection location within the currentcamera view volume; (f) determining 2D imposter locations within thecurrent camera view volume at which 2D imposters will be displayed, the2D imposter locations being determined as a function of a modulateddistance from a current camera position; (g) forming contiguous sets ofimposter data structures associated with predefined locations that arenot interrupted by one of: (i) locations at which 3D graphical objectswill be rendered; and (ii) locations that are outside the view volume;and (h) invoking a single draw primitive for each contiguous set ofimposter data structures to render 2D imposters for each contiguous setof imposter data structures, thereby displaying 2D imposters at thepredefined locations.
 2. The method of claim 1, wherein the 3D graphicalobjects comprise virtual spectators in a virtual arena.
 3. The method ofclaim 1, wherein the step of predefining the hierarchical data structurecomprises the steps of: (a) iteratively dividing the predefinedlocations into a plurality of levels of groups, wherein the groups ateach level comprise substantially equal numbers of predefined locations;and (b) arranging plurality of levels of groups in a contiguous quadorder.
 4. The method of claim 1 wherein an individual imposter datastructure comprises: (a) one of the predefined locations within thevirtual space; (b) a plurality of vertex data elements, wherein eachvertex data element is assigned a unique vertex identifier; and (c) atexture identifier specifying a texture associated with the individualimposter data structure.
 5. The method of claim 1, wherein the step ofdetermining a common projection location comprises the steps of: (a)determining a plurality of group centers, each group center comprising acenter location of each hierarchical group that is within a predefineddistance of a current camera location; (b) determining a plurality ofmodulation functions, each modulation function corresponding to eachgroup center as a function of at least: (i) the distance between a groupcenter and a centroid of the camera view volume; and (ii) whether agroup center is within the camera view volume; and (c) computing aweighted average of the group centers as a function of a sum of thegroup centers and a sum of the modulation functions.
 6. The method ofclaim 1, wherein the step of generating each of the 2D imposterscomprises the steps of: (a) determining a current animation stepassociated with each of the 3D graphical objects; (b) generating a posed3D graphical object for each of the 3D graphical objects as a functionof the current animation step associated with each of the 3D graphicalobjects; and (c) generating a projected image of each posed 3D graphicalobject positioned at the common projection location.
 7. The method ofclaim 6, further comprising the step of defining a rectangle size forthe projected image as a function of a proximity of the current cameraposition to the predefined locations.
 8. The method of claim 1, whereinthe step of determining 2D imposter locations comprises the steps of:(a) determining the modulated distance from the current camera positionas a function of a predefined radius and at least a current zoom factor;and (b) selecting predefined locations that are within the modulateddistance from the current camera position and are within the camera viewvolume.
 9. The method of claim 1, wherein the step of forming contiguoussets of imposter data structures comprises the steps of: (a) determiningvisible hierarchical groups from the hierarchical groups of imposterdata structures that include at least one predefined location within thecamera view volume; (b) determining any 3D hierarchical group from thevisible hierarchical groups that include at least one predefinedlocation within a predefined 3D threshold distance from the currentcamera position, thereby determining the visible hierarchical groupsthat will be rendered with 3D graphical objects rather than 2Dimposters; and (c) selecting the visible hierarchical groups thatinclude adjacent imposter data structures not interrupted by a 3Dhierarchical group.
 10. The method of claim 1, wherein prior to the stepof invoking a single draw primitive, further comprising the steps of:(a) sorting the contiguous sets of imposter data structures into anorder, from a contiguous set that is closest to the current cameraposition, to a contiguous set that is farthest from the current cameraposition; and (b) rendering 3D graphical objects at predefined locationsthat are within the camera view volume and are associated withhierarchical groups that are within a predefined distance from thecurrent camera position.
 11. A memory medium on which are stored machineinstructions for carrying out the steps of claim
 1. 12. A system fordynamically displaying two-dimensional (2D) imposters ofthree-dimensional (3D) graphical objects relative to an arbitrarilymovable camera position, wherein each 2D imposter comprises a projectionof one of the 3D graphical objects, comprising: (a) a processor; (b) adisplay in communication with the processor; and (c) a memory incommunication with the processor, the memory storing machineinstructions that cause the processor to carry out a plurality offunctions, including: (i) predefining locations within a virtual space,wherein each location defines a position at which one of: (1) a 3Dgraphical object will be displayed; and (2) a 2D imposter will bedisplayed; (ii) predefining a hierarchical data structure comprisinghierarchical groups of imposter data structures to be used in definingthe 2D imposters, wherein each one imposter data structure is associatedwith one of the predefined locations within the virtual space, andwherein the hierarchical groups are arranged in a contiguous quad order;(iii) determining a current camera view volume within the virtual space;(iv) determining a common projection location within the current cameraview volume as a function of a central location of the predefinedlocations associated with each hierarchical group of imposter datastructures; (v) generating each of the 2D imposters as a projection ofeach 3D graphical object positioned at the common projection locationwithin the current camera view volume; (vi) determining 2D imposterlocations within the current camera view volume at which 2D imposterswill be displayed, the 2D imposter locations determined as a function ofa modulated distance from a current camera position; (vii) formingcontiguous sets of imposter data structures associated with predefinedlocations that are not interrupted by one of: (1) locations at which 3Dgraphical objects will be rendered; and (2) locations that are outsidethe view volume; and (viii) invoking a single draw primitive for eachcontiguous set of imposter data structures to render 2D imposters foreach contiguous set of imposter data structures, thereby displaying 2Dimposters at the predefined locations that are not interrupted bylocations at which 3D graphical objects will be rendered.
 13. The systemof claim 12, wherein the 3D graphical objects comprise virtualspectators in a virtual arena.
 14. The system of claim 12, wherein themachine instructions further cause the processor to carry out thefunctions of: (a) iteratively dividing the predefined locations into aplurality of levels of groups, wherein the groups at each level comprisesubstantially equal numbers of predefined locations; and (b) arrangingplurality of levels of groups in a contiguous quad order.
 15. The systemof claim 12, wherein an individual imposter data structure comprises:(a) one of the predefined locations within the virtual space; (b) aplurality of vertex data elements, wherein each vertex data element isassigned a unique vertex identifier; and (c) a texture identifierspecifying a texture associated with the individual imposter datastructure.
 16. The system of claim 12, wherein the machine instructionsfurther cause the processor to carry out the functions of: (a)determining a plurality of group centers, each group center comprising acenter location of each hierarchical group that is within a predefineddistance of a current camera location; (b) determining a plurality ofmodulation functions, each modulation function corresponding to eachgroup center as a function of at least: (i) the distance between a groupcenter and a centroid of the camera view volume; and (ii) whether agroup center is within the camera view volume; and (c) computing aweighted average of the group centers as a function of a sum of thegroup centers and a sum of the modulation functions.
 17. The system ofclaim 12, wherein the machine instructions further cause the processorto carry out the functions of: (a) determining a current animation stepassociated with each of the 3D graphical objects; (b) generating a posed3D graphical object for each of the 3D graphical objects as a functionof the current animation step associated with each of the 3D graphicalobjects; and (c) generating a projected image of each posed 3D graphicalobject positioned at the common projection location.
 18. The system ofclaim 12, wherein the machine instructions further cause the processorto carry out the functions of: (a) determining the modulated distancefrom the current camera position as a function of a predefined radiusand at least a current zoom factor; and (b) selecting predefinedlocations that are within the modulated distance from the current cameraposition and are within the camera view volume.
 19. The system of claim12, wherein the machine instructions further cause the processor tocarry out the functions of: (a) determining visible hierarchical groupsfrom the hierarchical groups of imposter data structures that include atleast one predefined location within the camera view volume; (b)determining any 3D hierarchical group from the visible hierarchicalgroups that include at least one predefined location within a predefined3D threshold distance from the current camera position, therebydetermining the visible hierarchical groups that will be rendered with3D graphical objects rather than 2D imposters; and (c) selecting thevisible hierarchical groups that include adjacent imposter datastructures not interrupted by a 3D hierarchical group.
 20. The system ofclaim 12, wherein the machine instructions further cause the processorto carry out the functions of: (a) sorting the contiguous sets ofimposter data structures into an order, from a contiguous set that isclosest to the current camera position, to a contiguous set that isfarthest from the current camera position; and (b) rendering 3Dgraphical objects at predefined locations that are within the cameraview volume and are associated with hierarchical groups that are withina predefined distance from the current camera position.